Three-dimensional visual scenes are, using one or more computers, rendered haptically (i.e., to provide a tactile sensation) by a scene owner and graphically (i.e., to provide a visual representation) by a scene displayer and used in a hapto-visual system in various design, testing, and other contexts. A scene typically includes one or more elements (or objects) which are to be rendered haptically and graphically. A scene may include an object which is only to be rendered haptically but not graphically, and/or there may also objects which are only graphically rendered. Due to limited processor computation capacity, complex hapto-visual systems may require the separation of scene owners and scene displayers onto different computer systems that are interconnected via a network. The scenes contain a large amount of haptic and visual information, and typically, dedicated high bandwidth networks are required to allow information to pass from the scene owner to the scene displayer.
In addition, only unidirectional communication from the scene owner to the scene displayer is permitted in the prior art. Also, the communication is typically one-to-one or one-to-many.
Accordingly, known systems which render scenes haptically and graphically suffer from a number of disadvantages.
Certain applications require real-time capabilities for certain components of a system, e.g., a haptic rendering algorithm that calculates the force to be applied, or network latency compensation. However, many haptic device manufacturers provide drivers that only support the major operating system providers, who provide non-real-time operating systems. Accordingly, in the prior art, it is generally very difficult to find driver support for a real-time operating system (RTOS).
In addition to the requirement for real-time capabilities for certain components of the system, however, other parts of the system typically act only as observatory or supervisory parts of the overall system (e.g., parameter updates). Accordingly, in the prior art systems which include haptic and graphic components, the haptic components tend to be real-time sensitive, and the graphic components do not tend to be real-time sensitive.
In the prior art, in order to try to make real-time applications to run in a non-RTOS, a significant amount of work is required. For example, a real-time kernel is installed underneath an existing non-RTOS. This allows the real-time application process to have higher priority in using the CPU than any other processes that the non-RTOS has, even the non-RTOS itself. In this approach, a real-time application is allowed to be “run” on a non-RTOS, or more accurately, to appear to do so. However, the application is not truly running on the non-RTOS, rather, it is merely going through a backdoor to the real-time kernel underneath the non-RTOS. Because of this, a third party software development kit cannot be used in a real-time application, because any real-time application has to be run in a specialized environment underneath the non-RTOS. In addition, real-time kernels typically require run-time licenses from the kernel developers for each target that the application would run on, thus increasing the cost of application deployment.
There is therefore a need for method and a system that will overcome or mitigate one or more of the disadvantages of the prior art.